[app] Remove external_clusters flag #37817
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
maciejbaczmanski
force-pushed
the
matter_external_clusters
branch
from
8fcd2c1 to
a5422f7
Compare
|
PR #37817: Size comparison from 50aa1d3 to a5422f7 Full report (60 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, linux, nxp, psoc6, qpg, stm32, tizen)
|
andy31415
reviewed
Feb 28, 2025
| " (hint: add to src/app/zap_cluster_list.json)" % (side, cluster)) | ||
|
|
||
| cluster_sources.update(source_map[cluster]) | ||
| if cluster in source_map: |
There was a problem hiding this comment.
we seem to lose an exception here and silently ignore a cluster that is not in a source map.
Silently skipping things will be hard to debug.
There was a problem hiding this comment.
we need a warning at a minimum or a flag that makes it "these are known non-sdk clusters, skip" (which I imagine is what the old flag was supposed to do)
There was a problem hiding this comment.
Hi @andy31415 . In my opinion the exception is redundant:
- if vendor/end user adds a custom cluster, they must modify the .json file, even if they source custom cluster separately (for example they don't want to put the implementation in
"${_app_root}/clusters/${cluster}/${cluster}.cpp") - if new common cluster is created, but not added to
zap_cluster_list.json, build will fail as files are not sourced. I aggree that it would be worth adding a note, but I'm not sure if Build GN can parse python's stderr output inexec_script?
Alternatively I could convert the external_clusters flag from list to just boolean flag, so that it should be only set if we use external clusters, but without a burden of listing all of them every time?
`external_clusters` flag is redundant as if an external cluster is created without correct implementation, build will fail anyway. Without the flag, clusters not provided in `zap_cluster_list.json` can be skipped without requiring to always provide full list of custom clusters. Signed-off-by: Maciej Baczmanski <maciej.baczmanski@nordicsemi.no>
maciejbaczmanski
force-pushed
the
matter_external_clusters
branch
from
a5422f7 to
cc09a20
Compare
|
PR #37817: Size comparison from b205837 to cc09a20 Full report (74 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
ArekBalysNordic
approved these changes
Mar 3, 2025
|
Just found that |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
external_clustersflag is redundant as if an external cluster is created without correct implementation, build will fail anyway. Without the flag, clusters not provided inzap_cluster_list.jsoncan be skipped without requiring to always provide full list of custom clusters.Testing
tested on nrfconnect build with custom cluster added